The
main character on the cryptographic stage is the key. A key contains
the algorithm, the sequences of instructions which is used in the
various cryptographic functions that SQL Server provides to encrypt and
decrypt data.
An encryption function uses
the key to describe how the plain text will be converted into cipher
text. Likewise, without the key, the decryption process cannot occur.
Many types of keys are
available to work with the cryptography features and functions of SQL
Server, arranged into a distinct hierarchy.
Cryptographic Key Hierarchy
The keys that are used with
the cryptography features of SQL Server are structured in a layered, or
hierarchical, composition. Each layer of keys encrypts the underlying
layer of keys and ultimately the data itself, as shown in Figure 1.
This hierarchy provides
a highly secure infrastructure for sensitive data. At the top of the
hierarchy is the service master key, which operates at the SQL Server
Instance level and is used to protect the database master keys, in each
database. This renders the database useless outside of its instance. In
addition, without the use of the service master key to protect the
database master key, the database master key must be explicitly opened
prior to its use.
The database master key is
used to encrypt the private keys for asymmetric keys and certificates
within a database. By applying this level of protection these private
keys cannot be decrypted outside of the database unless the database
master key is also provided.
Asymmetric keys and
certificates are used to protect the other private keys, symmetric keys
and data contained within the database. The symmetric keys within the
database are used to protect other symmetric keys as well as data
within the database. This inner dependency provides a level of security
that is much more resistant to unauthorized access.
Service Master Key
The Service Master Key is
encrypted using the machine key from the Windows Data Protection API
(DPAPI), using the password of the Windows Service Account credentials
of the server in which the SQL Server instance is installed.
When an instance of SQL
Server is installed, and its service is started for the first time, the
service master key is created. There can be only one service master key
per instance.
The catalog view sys.symmetric_keys can be used to verify the service master key's existence, as shown in Listing 1. The service master key is identified with the name ##MS_ServiceMasterKey##.
The service master key is often
used to provide protection to other keys within a database. It is also
a critical component of the Transparent Data Encryption (TDE) feature
of SQL Server 2008.
Database Master Key
This key is unique to each
database within the SQL Server instance. If an item is encrypted using
the database master key, it cannot be decrypted outside of that
database. The database master key is not automatically generated when a
database is created, instead it is created using the CREATE MASTER KEY command, as shown in Listing 2.
You can verify the existence of the database master key by querying the sys.symmetric_keys
catalog view, using either the master database or the database for
which the database master key was created. The database master key is
identified with the name ##MS_DatabaseMasterKey## .
A database master key can be
used to protect the asymmetric keys, certificates, as well as sensitive
data, contained within the database. The database master key is
protected through the use of the service master key and/or a password.
Asymmetric Key
Asymmetric keys consist of a
public key, which is distributed to selected individuals, and a private
key to which access remains highly restricted. In SQL Server, the
public key can decrypt data that has been encrypted by a private key
and vice-versa.
Asymmetric keys can be created within a database through the execution of the CREATE ASYMMETRIC KEY command.
Again, you can query sys.asymmetric_keys to verify that the asymmetric key was successfully created.
Asymmetric keys are used to
protect other keys within the database, as well as sensitive data. This
type of key is highly resource intensive and, when used to protect
sensitive data, it should be used with smaller data sets or messages.
Certificates
A certificate is used in much
the same way as an asymmetric key in that it involves a public/private
key pair. The primary difference is that a certificate private key is
digitally associated with an individual or device whereas the
asymmetric key is not. The industry standard known as the Internet
X.509 Private Key Infrastructure (PKI) defines the contents and
signature requirements for a valid certificate, and certificate private
key.
In SQL Server, a
certificate's private key can either be imported from an external
assembly, or generated within the database. In the latter case, this is
called a self-signed certificate. The certificate private key that is generated within SQL Server is in compliance with the PKI standard.
Listing 4 demonstrates the creation of a certificate can be created within a database using the CREATECERTIFICATE command.
Once again, you can query sys.asymmetric_keys to verify the existence of the certificate in the database in which you attempted to create it.
When
creating a certificate, you can specify arguments that define its
activation date (START_DATE) and expiration date (EXPIRY_DATE).
These properties can be used in the management of a certificate's
lifecycle. SQL Server does not enforce the activation and expiry dates
that are associated with a certificate. Additional logic, or the use of
the Extensible Key Management (EKM) feature of SQL Server, must be
employed to enforce these dates.
Certificates are used to protect other keys within the database as well as sensitive data.
Symmetric Key
When an item is
encrypted using a symmetric key it must be decrypted using that same
key. The service master key, database master keys and database
encryption keys are all examples of symmetric keys. Additional
symmetric keys can be created within a database using the CREATE SYMMETRIC KEY command, as shown in Listing 5.
Querying sys.symmetric_keys,
in the context of the database in which the symmetric key was
generated, will verify that the symmetric key was successfully created.
Symmetric keys are used to
protect other keys within the database as well as sensitive data.
Symmetric keys can be protected by other symmetric keys, asymmetric
keys, certificates and passwords.
Database Encryption Key
The database encryption key
was introduced in SQL Server 2008. This key is specifically designed to
support the Transparent Data Encryption (TDE) feature of that product.
The purpose of this key is to perform the encryption/decryption process
on the physical files and file groups of the database.
The database encryption key
is located in the user database while the asymmetric key, or a
certificate, that protects the database encryption key resides in the
master database. This is not only necessary to decrypt the key that
protects the physical files of the database; but also provides the
"transparent" opening of the database encryption key and cryptographic
functionality without the requirement of additional coding to manage it.
Database encryption keys can be created within a database through the execution of the CREATE DATABASE ENCRYPTION KEY
command. Due to this key's exclusive use by the Transparent Data
Encryption feature of SQL Server 2008.
Passwords
In this day and age the
concept of a password is one that is widely understood. These are the
strings of characters used to login to computer systems, check our
e-mail, activate household security systems and access voicemail
messages. In SQL Server, passwords are an option that is available to
protect other keys within a database. For example, the use of a
symmetric key requires it to be opened prior to its reference in
cryptographic processes. If a symmetric key is protected by a password,
the string of characters that consists of the protecting password must
be passed for it to be opened.
Passwords are defined with an argument to the key's respective CREATE
commands. Each of the keys covered in this chapter, with the exception
of the service master key, include the ENCRYPTION BY PASSWORD argument
in their creation script examples.
An alternative to using
passwords to protect the keys within the database is the use of
symmetric keys, asymmetric keys or certificates. Password protecting
keys improve the portability of keys since they are not dependent upon
items that are database or instance specific; although, this
portability does allow the protected item to be restored to another
instance and compromised to reveal its contents therefore reducing its
level of security.
